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IMPROVING  SYSTEMS  DELIVERY:   A  MANAGERIAL  PERSPECTIVE 
John  F.  Rockart  and  J.  Debra  Hofman 


ABSTRACT 

In  order  to  improve  their  capability  to  deliver  information  systems  more  quickly, 
inexpensively,  and  effectively,  many  organizations  today  are  considering  major  investments 
in  new  systems  development  tools,  methods,  and  techniques.  Many  are  struggling  with  the 
decision  of  whether  to  invest  in  CASE  tools,  other  types  of  tools  and  methods,  software 
packages  or  nothing  at  all.  The  decision,  however,  is  not  an  easy  one.  Based  on 
conversations  with  senior  managers  in  twelve  companies,  a  framework  emerges  which  can 
be  used  to  address  the  many  issues  which  are  involved.  Rethinking  and  investing  in  a 
redesigned  systems  development  process  is  critical  and  must  be  anchored  in  the  business 
context.  The  associated  issues  are  major,  strategic  in  nature,  and  require  significant  senior 
management  attention. 
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IMPROVING  SYSTEMS  DELIVERY:    A  MANAGERIAL  PERSPECTIVE 


Scene:  Vie  office  of  the  manager  of  a  strategic  business  unit  in  a  major 
corporation. 

Vice  President  of  Information  Systems:  "We  just  have  to  build  systems  faster, 
better,  at  lower  cost,  and  in  a  way  that  they  are  easier  to  maintain  and  change. 
Jliat's  the  reason  we're  going  to  bring  in  CASE  technology." 

SBU  Manager:  "I'm  told  that's  expensive  to  do  and  involves  major  change  in 
your  organization.  We  ought  not  to  be  building  systems  at  all!  Tliere  are  good 
"packages"  on  the  market  today.  Let's  use  them  --  it's  cheaper  and  faster  --  and 
we  know  you  can  install  them.    We  saw  you  do  it  over  in  accounting." 


INTRODUCTION 

Variations  on  the  conversation  described  above  can  be  heard  today  in  many 
organizations.  In  an  era  of  cost-cutting  and  flat  budgets,  many  chief  information  officers 
(CIOs)  are  requesting  significant  dollar  outlays  to  radically  change  the  ways  in  which  systems 
are  developed  and  to  make  the  information  systems  (IS)  organization  more  productive.  In 
some  cases,  the  IS  managers  want  to  buy  computer  aided  software  engineering  (CASE)  tools 
that  help  to  automate  the  process  of  developing  systems;  in  others,  they  want  to  introduce 
an  "object-oriented"  approach;  in  still  others,  they  are  bringing  in  new  development 
methods  in  combination  with  the  above. 

At  the  same  time,  others  in  the  organization  are  challenging  the  wisdom  of  the 
investment  that  this  would  require.     For  many,  the  benefits  to  be  achieved  from  an 


Object-oriented  systems  development  is  a  relative  newcomer  to  the  world  of  business  systems,  and 
represents  a  different  approach  to  developing  systems  --  both  in  terms  of  methodology  and  the  tools  required 
to  support  it  --  than  its  predecessors.  Where  a  traditional  system  is  composed  of  programs  that  define 
procedures  and  use  data,  an  object-oriented  system  is  composed  of  self-contained  objects,  containing  both 
procedures  and  data,  that  send  messages  to  each  other. 


investment  in  the  process  of  developing  systems  are  unclear.  Year  after  year,  they  have 
witnessed  constant  increases  in  IS  expenditures.  They  have  been  through  myriad  "waves  of 
the  future"  and  "silver  bullets":  fourth-generation  languages,  data-centered  design,  expert 
systems,  prototyping,  relational  technology,  and  others.  Still,  there  is  a  software  bottleneck. 
For  many  companies,  information  systems  are  not  only  on  the  critical  path  to  getting  a  new 
product  or  service  to  market,  they  are  the  stumbling  block  on  that  path. 

Suggestions  by  the  IS  organization  to  improve  the  situation,  however,  are  meeting 
with  some  skepticism  today.  Rather  than  invest  large  sums  in  new  IS  development  methods, 
many  business  managers  propose  an  alternative  that  they  believe  will  be  faster  and  cheaper 
~  buy  packages.  Instead  of  building  the  needed  information  systems  internally  and 
continually  investing  in  rapidly  changing  new  methodologies,  tools,  or  techniques,  they 
propose  to  purchase  off-the-shelf  software  packages  wherever  possible. 

Which  approach  is  correct?  The  answer  is  far  more  complex  than  the  choice  of  the 
tools  alone.  Any  decision  about  IS  tools,  methods,  and  approaches  -  whether  CASE,  fourth- 
generation  languages,  object-oriented  development,  or  software  packages  -  must  be 
anchored  in  the  context  of  the  company's  future  business  environment  and  the  systems 
environment  that  will  be  needed  to  support  this  business  scenario.  Only  then  can  the 
discussion  about  IS  tools  and  methods  realistically  begin.  Moreover,  the  decision  ultimately 
is  not  a  question  of  CASE  tools  or  packages  or  prototyping  or  fourth-generation  languages. 
Rather,  it  is  about  choosing  a  portfolio  of  approaches  or  delivery  mechanisms  that  will  allow 
the  fulfillment  of  the  organization's  business  vision. 

Moving  to  new  systems  development  technologies  requires  considerable  time  and 
thought  on  the  part  of  both  line  and  IS  managers  and  involves  a  major  investment  of  dollars 
and  other  resources.  In  fact,  it  is  a  prime  example  of  "business  process  redesign"  [Hammer, 
1990;  Davenport  &  Short,  1990]  for  it  involves  extensively  reworking  the  way  in  which  the 
fundamental   process   in   the   information   systems   function   ~   the   process   of  systems 


development  --  is  carried  out.     The  decision  is  major,  and  requires  significant  senior 
management  attention. 

The  conclusions  about  improving  the  systems  delivery  process  presented  here  arose 
from  discussions  with  senior  managers  in  twelve  companies  that  are  leaders  in  the  use  and 
management  of  information  technology.  All  twelve  companies  were  aggressively 
implementing  new  approaches  to  systems  development.  The  companies  ranged  in  size  from 
$500  million  to  $30  billion,  and  industries  included  finance,  insurance,  manufacturing, 
petroleum,  chemical,  and  computers.  Interviewees  typically  included  the  senior  IS  executive 
and  three  to  five  managers  reporting  to  him  or  her.  In  some  cases,  we  interviewed  senior 
line  managers  as  well.   Each  discussion  generally  lasted  from  one  to  two  hours. 

Significantly,  these  twelve  companies  were  in  the  minority  in  terms  of  their  level  of 
involvement  with  new  tools  and  approaches.  The  majority  of  companies  we  contacted  in  the 
search  for  appropriate  study  sites  were  either  just  experimenting  with  new  tools  on  a  small 
scale  or  continuing  with  the  old  tools  and  approaches.  Although  senior  IS  managers,  and 
sometimes  even  line  managers,  were  clearly  aware  of  the  need  to  improve  systems 
development,  the  funding  had  not  been  committed.  The  reasons  included  budget 
constraints,  the  perceived  high  cost  of  investment  in  appropriate  hardware  and  software,  and 
doubt  about  the  capabilities  of  available  development  tools. 

In  contrast,  our  study  sites  were  convinced  that  they  had  to  improve  systems 
development  and  were  aggressively  investing  to  do  so.  Although  there  were  distinct 
differences  in  the  approaches  of  these  companies,  a  pattern  emerged  as  shown  in  Figure  1. 
This  framework  will  be  used  to  highlight  the  similarities  as  well  as  the  differences  among 
these  companies.  The  framework  describes  a  two-phase  process.  In  the  first,  or  envisioning 
phase,  management  either  implicitly  or  explicitly  considered  three  future  "environments"  for 
the  business.   These  are  as  follows: 


•  the  projected  business  environment  --  a  vision  of  the  future  business  organization  and 
the  way  in  which  the  organization  must  operate  to  be  effective  in  the  market(s)  that 
it  serves; 

•  the  projected  systems  environment  -  a  strategic  vision  of  the  systems  environment 
that  will  enable  the  business  vision  (an  IS  version  of  an  articulated  "strategic  intent" 
[Hamel  and  Prahalad,  1989])(See  also  Henderson  and  Venkatraman,  1990.);  and 

•  the  projected  development  environment"  --  the  portfolio  of  delivery  mechanisms 
(including  tools,  methods,  and  approaches)  that  will  enable  the  delivery  of  systems 
to  meet  the  needs  of  the  projected  systems  environment. 

The  second  phase  encompassed  the  transition  from  the  current  environment  to  the 
projected  development  environment.  Action  plans  for  this  phase  included  the  selection  of 
specific  tools  and  methods  to  be  installed  in  the  short  and  medium  term  to  migrate  toward 
the  projected  development  environment,  taking  into  account  both  enabling  and  constraining 
factors  in  the  current  environment. 

The  four  environments  depicted  in  the  framework  are  directly  related:  the  outcome 
of  one  either  drives  or  is  affected  by  the  next.  Figure  1  highlights  the  fact  that  the  decision 
regarding  specific  IS  tools  and  methods  --  the  transition  phase  --  was  made  only  after  careful 
consideration  of  the  environments  noted  in  Phase  1. 


^  In  this  context,  "development  environment"  refers  to  the  full  solution  set  by  which  the  required 
information  systems  will  be  delivered  to  the  organization  in  the  future  --  the  portfolio  of  types  of  tools, 
methods,  techniques,  database  structure,  approaches,  and  so  on.  An  "approach"  might  include,  for  example, 
the  use  of  off-the-shelf  software  packages  to  deliver  systems  solutions  whenever  possible  or  a  decision  to 
outsource  data  center  operations.  While  the  projected  systems  environment  defines  "what,"  the  projected 
development  environment  defines  "how." 

^  We  recognize  the  reciprocal  nature  of  the  interaction  among  these  components.  That  is,  while  the 
projected  business  environment  shaped  the  choices  in  the  projected  systems  environment,  the  projected  systems 
environment  in  turn  shaped  the  projected  business  environment.  And,  while  the  projected  systems 
environment  shaped  the  projected  development  environment,  the  reverse  was  clearly  true  here  as  well.  The 
strategic  planning  underlying  the  decisions  made  in  the  projected  business  and  systems  environment  is  a 
complex  and  highly  interactive  process.  However,  for  the  purpose  of  clarity,  we  focus  here  on  the  one 
direction  described  above  and  depicted  in  Figure  1. 
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In  the  following,  we  will  discuss  this  process  and  the  actions  of  these  companies  in 
greater  detail.  Three  of  the  twelve  companies  will  be  used  as  representative  examples 
throughout  this  discussion.  The  first  company  is  a  major  provider  of  property  and  casualty 
as  well  as  life  insurance  products.  The  second  company  is  a  Fortune  100,  multinational, 
chemical  firm.   The  third  company  is  a  multinational  energy  company. 

PHASE  1:    ENVISIONING  THE  FUTURE  ENVIRONMENT 

In  describing  the  process  by  which  choices  are  made  about  current  and  future  IS 
development  tools,  the  people  we  interviewed  repeatedly  noted  each  of  the  four 
environments  in  the  framework,  in  part  or  in  total.  In  this  section,  we  describe  Phase  1  of 
the  framework  --  the  three-step  process  of  envisioning  the  future  development  environment. 
The  scenarios  for  the  first  three  environments,  as  developed  by  most  of  the  IS  directors  with 
whom  we  spoke,  were  surprisingly  similar.  Although  the  industries  were  different,  the 
conditions  and  resulting  requirements  that  were  described  were  much  the  same. 

The  Projected  Business  Environment 

The  three  representative  companies  described  their  future  business  environments  as 
follows: 


The  Insurance  Company.  Tlie  insurance  provider  described  the  demand  for  new 
products  as  "frenetic."  Insurance  products  themselves  are  becoming  commodities, 
and  service  quality  is  fast  becoming  the  competitive  differentiator  Tfie 
introduction  of  new  products  is  necessary  just  to  stay  in  the  game,  and  new 
products  are  developed  almost  daily. 

The  Chemical  Firm.  For  most  of  its  history,  this  firm  had  been  organized  by 
product.  Each  of  the  approximately  thirty  divisions  was  relatively  autonomous, 
subject  only  to  a  minimum  of  central  direction  in  financial  and  personnel 
matters.  Wliere  scale  was  an  issue,  certain  corporate  functions  (e.g.,  the 
management  of  data  centers)  were  centralized. 


Vie  advent  of  a  new  CEO  three  years  ago  is  changing  this.  Citing  the  need  for 
globalization,  a  customer  emphasis,  and  empowerment  through  information  at 
all  levels  in  the  organization,  as  well  as  other  factors,  the  CEO  is  steadily 
integrating  the  parts  of  the  organization.  He  is  also  imbuing  a  team-oriented 
philosophy  and  reorganizing  around  customer  segments. 

The  Energy  Company.  In  1987,  one  of  the  company's  divisions  conducted  a 
strategic  review  of  its  information  systems  needs  and  capabilities.  Management 
realized  that  integration  across  subunits  in  the  company  had  become  very 
important  --  that,  for  example,  what  happened  in  the  refinery  was  integrally  tied 
to  operations  in  the  service  stations.  Lack  of  integration  was  hurting 
performance,  both  in  terms  of  customer  service  and  the  financial  results. 
Management  also  recognized  that  change  in  the  industry  had  become  the  norm, 
and  that  access  to  accurate,  timely,  and  consistent  information  had  become 
critical  to  nmning  the  business. 


Although  each  company  is  in  a  different  industry  and  has  specific  issues  that  apply 
to  that  industry,  there  is  a  centrality  to  the  trends  that  were  noted.  All  of  the  companies 
noted  that  the  pace  of  change  has  quickened  considerably  and  promises  to  continue.  For 
almost  all,  competition  has  both  increased  dramatically  and  expanded  into  the  global  arena. 
Time  has  become  a  critical  competitive  differentiator:  time  to  market  for  new  products, 
manufacturing  cycle  time  for  existing  products,  and  timeliness  of  decision  making,  all 
previously  important,  are  now  critical.  The  focus  is  now  on  the  customer  and  on  quality  as 
perceived  by  the  customer. 

Companies  are  taking  three  major  actions  to  respond  to  these  trends,  all  of  which 
involve  significant  changes  in  the  way  they  are  being  operated  and  structured.  First, 
companies  are  realigning  along  "business  process"  lines  [Davenport  &  Short,  1990;  Hammer, 
1990]  in  order  to  serve  customers  faster  and  with  better  quality.  Second,  many  organizations 
are  either  physically  combining  or  managerially  restructuring  formerly  independent  business 
units  in  order  to  reduce  cost  and  improve  customer  service.  Increasingly,  the  parts  of  the 
organization  (functions,  strategic  business  units,  divisions,  etc.)  are  seen  as  interdependent 
rather  than  independent  [Rockart  &  Short,  1989].  Finally,  firms  are  both  decreasing  the 
number  of  employees  and  "empowering"  these  employees  with  the  information  needed  to 


carry  out  their  tasks.    Flatter  and  leaner,  but  information  rich,  organizations  are  beginning 
to  emerge  in  order  to  reduce  costs,  speed  decision  making,  and  serve  customers. 

The  longer-term  outlook  is  less  clear.  However,  most  executives  agree  on  one  major 
perspective  on  the  future.  It  will  be  a  future  in  which  ongoing  change,  both  external  and 
internal,  will  have  to  be  reacted  to  continually. 

The  Projected  Systems  Environment 

The  projected  systems  environment,  as  related  to  us,  was  based  on  the  envisioned 
business  environment.  Although  each  organization  faced  a  different  industry  and  internal 
environment,  the  projected  systems  environments  had  much  in  common.  A  brief  look  at 
some  aspects  of  our  three  example  companies  provides  some  insights: 


The  Insurance  Company.  Tfiis  company  is  faced  with  a  mismatch  between  its 
information  systems  environment  and  its  business  environment.  Currently,  each 
new  product  requires  the  development  of  a  completely  new  system.  Vie  sooner 
the  system  is  developed,  the  sooner  the  company  can  realize  the  added  revenue 
from  the  product.  One  manager  described  the  business  this  way:  "Wliat  we  do 
here  is  talk  [sell]  all  day,  and  code  all  night."  In  the  most  fundamental  way,  the 
development  of  each  system  is  now  on  the  critical  path  of  new  product 
development.  Viis  company,  therefore,  has  decided  that  it  must  be  able  to 
develop  high-quality  systems  quickly.  As  such,  it  has  outlined  a  technology  vision 
of  using  flexible,  modular  systems  that  can  be  easily  customized  for  each  new 
product. 

The  Chemical  Firm.  Based  on  the  need  for  globalization,  integration,  a  customer 
and  team  orientation,  and  common  business  processes,  this  firm  recognizes  that 
information  must  be  easily  accessible  for  empowered  employees.  In  addition, 
transaction  systems  will  need  to  be  flexible  and  integrated,  to  transcend  traditional 
boundaries,  and  to  support  common  business  practices. 

The  Energy  Company.  Senior  managers  in  this  company  realized  they  had  a 
widely  diverse  set  of  technologies  (hardware  and  software)  and  redundant, 
unreliable,  and  difficult-to-access  data.  Viey  envisioned:  I)  an  enterprisewide 
system  comprising  horizontally-integrated  subsystems  that  could  be  changed  to 
respond  quickly  to  external  changes  and  2)  a  shared  corporate  data  environment 
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--  an  information  architecture  --  ihat  would  provide  consistent  and  timeiv 
information  to  its  users. 


The  differences  described  above  were  dominated  by  the  underlying  similarities  of  the 
ultimate  systems  environment  as  proposed  by  our  study  sites.  All  organizations  expressed 
a  need  for  high  quality,  flexible  systems  that  can  be  changed  quickly  to  meet  rapidly  evolving 
business  needs.  These  systems  should  be  easily  transportable  from  one  part  of  the  global 
organization  to  another  --  perhaps  cloning  the  fundamental  logic  to  reflect  business  practices 
that  need  to  be  the  same  but  allowing  for  quick  and  easy  tailoring  of  some  portions  of  each 
system  to  reflect  local  differences.  Finally,  all  noted  the  need  for  a  flexible  technological 
environment  in  which  new  technologies  can  be  introduced  as  they  become  available  without 
major  disruption  to  the  existing  technology  foundation. 

Not  only  will  the  characteristics  of  the  systems  environment  be  different  than  in  the 
past,  but  the  types  of  systems  that  will  be  supported  by  this  environment  will  be  different  as 
well.  For  organizations  with  the  above  technological  vision,  the  information  systems  of  the 
past  no  longer  suffice.  Most  of  these  systems,  which  we  will  refer  to  as  transaction  systems 
(TS),  were  primarily  developed  to  process  the  operational  paperwork  of  the  firm.  Built  in 
the  1960s,  70s,  and  80s,  they  reflected  the  organizations  of  their  times:  they  were  stand- 
alone, function-specific  systems  that  processed  transactions  for  tasks  such  as  payroll 
processing,  general  ledger,  and  material  requirements  planning.  Many  of  these  systems  drew 
upon,  processed,  and  produced  their  own  localized  data. 

The  kinds  of  information  systems  which  are  needed  to  support  the  process-oriented, 
interdependent,  and  information-rich  organization  of  today  are  vastly  different.  The 
organization  that  works  across  functional  (and  sometimes  divisional)  boundaries  needs 
supporting  cross-functional  transaction  systems,  where  the  focus  is  on  satisfying  end-to-end 
business  events  or  service  strategies  rather  than  discrete  activities.  Increasingly,  these 
systems  must  span  not  only  the  value  chain  but  also  multiple  business  units.  For  example, 
the  order  entry  system  of  the  past  must  become  the  order  logistics  management  system  of 


the  future,  managing  and  tracking  each  order  through  its  life  cycle  across  the  functions  of 
purchasing,  inventory  management,  manufacturing,  accounting,  and  distribution. 

With  regard  to  these  transaction  systems,  two  implications  are  clear.  First,  new 
systems  development,  long  overwhelmed  by  maintenance  of  existing  systems,  will  be 
necessary  if  process-oriented  systems  are  to  be  created.  The  investment  will  be  major. 
Second,  not  only  the  nature  of  the  systems  has  changed,  the  speed  with  which  they  are 
needed  and,  more  important,  with  which  they  must  be  changed  has  increased  as  well. 

At  the  same  time,  the  information  systems  needs  of  the  organization  are  no  longer 
limited  to  the  realm  of  transaction  systems.  A  world  of  plentiful  data,  text,  and  images  in 
which  timely  decisions  are  critical  requires  systems  that  allow  people  at  all  organizational 
levels  to  easily  access,  manipulate,  and  analyze  vast  amounts  of  information.  As  such, 
decision  support  systems,  executive  support  systems,  spreadsheets,  and  end-user  computing 
of  all  types  are  becoming  increasingly  integral  components  of  the  IS  portfolio.  We  refer  to 
this  class  of  systems  as  information  support  systems  (ISS).  In  the  past,  there  has  been  less 
emphasis  on  developing  these  systems  than  on  developing  TS.  However,  the  business 
environment  noted  above  has  shifted  the  priorities  toward  ISS  and  the  firm's  information 
architecture. 

Clearly,  there  has  been  a  dramatic  change  in  the  types  of  systems  that  the  IS 
organization  must  deliver.  We  have  discussed  here  two  major  classes  of  systems:  TS  and 
ISS.  A  company  may  have  additional  classes  that  are  unique  to  its  business  operations;  for 
example,  an  energy  company  has  geological  systems.  The  key  is  that  different  development 
strategies  are  necessary  for  the  different  classes  of  systems. 

The  Projected  Development  Environment 

Our  company  examples  described  their  projected  development  environments  as 
follows: 
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The  Insurance  Company.  Based  on  its  vision  of  flexible,  modular,  easily 
customizable  systems,  the  insurance  company  projected  a  development 
environment  that  will  include  systems  assembled  (rather  than  developed)  from 
standardized  components  residing  in  an  integrated  CASE  environment.  Some 
components  will  be  built  internally;  others  will  be  purchased  externally.  At  some 
point,  users  might  themselves  assemble  and  reassemble  these  components. 

The  Chemical  Firm.  TJiis  firm 's  most  significant  current  need  is  companywide 
access  to  consistent,  reliable  information.  As  such,  the  company  Ls  emphasizing 
systems,  databases,  and  software  that  gather,  store,  and  provide  access  to 
information  to  those  who  need  it;  transaction  systems  are  currently  taking  a  back 
seat.  Tfiis  firm 's  projected  development  environment  will  focus  on  tools  and 
methods  that  will  support  the  need  for  companywide  access  to  consistent,  reliable 
information  and  for  software  reuse  in  the  development  of  transaction  systems 
using  both  software  packages  and  CASE  tools. 

The  Energy  Company.  TJiis  company  envisions  an  integrated  CASE  tool 
environment  that  will  support  development  efforts,  help  create  integrated  systems, 
and  provide  a  common  repository  from  which  to  manage  information  resources. 
A  user  information  environment  would  also  be  established  with  tools  to  allow 
users  with  a  wide  variety  of  skills  and  capabilities  to  easily  access,  understand, 
analyze,  and  communicate  information. 


Certain  underlying  similarities  were  apparent  here  as  well.  The  future  development 
environment,  as  perceived  by  most  of  the  IS  executives  we  interviewed,  will  be  composed 
of  the  following: 


An  integrated  toolset'*  that  facilitates  the  reuse  of  systems  modules  within  a 
repository  and  an  associated  standardized  methodology  to  deliver  and  maintain  the 
transaction  class  of  systems.  The  modules  may  be  built  internally  or  purchased  in  the 
form  of  packages,  CASE-based  templates,  objects,  and  so  on. 


We  use  the  term  "integrated  toolset"  to  refer  generically  to  any  set  of  CASE  tools  that  are  logically  and 
structurally  interconnected.  Currently,  this  integration  can  be  accomplished  in  two  ways.  An  organization  may 
purchase  various  tools  from  different  vendors  that  support  the  different  phases  of  the  systems  development 
life  cycle  (i.e.,  design  tools,  code  generators,  etc.)  and  custom  build  the  bridges  between  them.  Alternatively, 
there  are  CASE  tools,  commonly  referred  to  as  I-CASE,  which  can  be  purchased  with  the  integration  or 
connections  already  built  in.  Please  note  that  CASE  tools  are  continually  evolving  --  when  we  refer  to 
"CASE,"  we  are  not  referring  only  to  the  current  incarnation  of  these  tools. 
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Flexible,  robust  access  tools  for  the  information  support  class  of  systems. 

Companywide  subject  and  information  databases  that  connect  the  two  classes  of 
systems,  that  is,  detailed  data  organized  around  "subjects"  for  the  TSs,  which  then 
feed  the  information  databases  for  the  ISSs. 


This  development  environment  is  very  different  from  what  most  companies  have 
today.  Given  the  dramatic  change  in  what  the  IS  department  must  deliver  to  the 
organization,  it  is  not  surprising  that  how  it  is  delivered  must  be  changed  dramatically  as 
well.  In  the  development  environment  of  yesterday,  the  IS  department  responded  separately 
to  requests  from  each  department.  Accounting  requested  its  general  ledger  and  accounts 
receivable  and  payable  systems.  Manufacturing  requested  its  scheduling  and  inventory 
systems.  The  personnel  department  requested  its  benefits  and  payroll  systems.  Moreover, 
in  a  company  organized  by  product  line,  it  was  common  for  divisional  manufacturing 
departments  to  request  separate  inventory  systems. 

But  as  described  earlier,  organizations  are  changing.  Given  a  process  focus, 
departments  and  sub-units  are  no  longer  independent,  but  interdependent.  If  the  product 
development  process  is  to  be  optimized,  research  and  development,  engineering,  and 
manufacturing  cannot  remain  completely  independent  anymore  --  they  must  be  coordinated 
and  play  their  parts  in  the  'arger  process.  The  new  organization  is  not  simply  a  remake  of 
the  old  one  with  connections  between  its  subunits;  it  is  a  reengineered  entity  that  is  now 
coordinated  rather  than  simply  connected.  In  the  same  way,  the  new  systems  development 
environment  is  not  simply  one  in  which  bridges  are  built  between  previously  unconnected 
systems;  it  is  now  one  in  which  the  relations  and  interconnections  between  systems  are 
articulated  and  well  understood  before  they  are  built  so  that  coordinated  systems  can  be 
developed,  where  each  system  is  one  component  within  an  integrated  framework. 


In  an  environment  such  as  this,  for  example,  the  design  of  one  system  would  include  the  capture  of 
information  that  could  be  used  by  other  component  systems  downstream. 
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In  such  a  development  environment,  the  creation  and  update  of  data  by  each  system 
is  structured  and  managed.  Portions  of  one  system's  design  can  be  used  in  another.  Systems 
are  portable  across  hardware  platforms,  and  parts  are  interchangeable:  any  element  can  be 
replaced  without  affecting  business  operations.  The  development  process  is  well  defined, 
flexible,  and  repeatable,  so  that  measures  of  the  quality,  effectiveness,  and  productivity  of 
the  process  and  its  resulting  systems  can  be  easily  captured  and  effectively  utilized  [Kemerer, 
1990].  In  summary,  this  is  a  structured,  integrated  environment  in  which  systems  are 
engineered  rather  than  built  ad  hoc.  And  it  is  this  engineered  characteristic  that  will 
eventually  allow  the  component  systems  to  be  delivered  quickly  and  changed  easily. 

New  types  of  methods,  tools,  and  approaches  will  be  needed  in  order  to  provide  this 
desired  development  environment.  As  discussed  earlier,  there  is  a  portfolio  of  solutions, 
where  different  approaches  may  be  appropriate  for  the  different  classes  of  systems  needed. 
In  the  previous  discussion,  we  drew  a  distinction  between  two  major  classes  of  systems: 
transaction  systems  and  information  support  systems.  The  connection  between  the  two 
classes  of  systems  is  the  data  they  must  share.^  Tools  and  methods  are  needed  to  support 
each  of  the  three  major  components:  TS,  ISS,  and  data.  For  the  TS  environment,  there 
must  be  tools  that  will  support  the  systems  developers,  tools  that  will  allow  the  coordination 
and  integration  described  above  and  that  will  result  in  structured  systems  that  are  easy  to 
change.  For  the  ISS  environment,  there  must  be  tools  that  will  allow  the  end  user  to  easily 
access  and  understand  data  from  multiple  sources  and  to  manipulate  and  analyze  it  as 
needed.  Finally,  there  must  be  data  management  tools  that  will  allow  the  structuring  of  the 
data,  will  insure  its  integrity,  and  will  provide  capabilities  to  migrate  pertinent  data  into 
information  data  bases. 


That  is.  in  addition  to  external  information,  information  support  systems  must  use  data  that  is  generated 
internally  by  the  transaction  systems.  Today,  this  data  is  scattered  throughout  the  organization  in  different 
forms,  and  much  of  it  is  relatively  inaccessible,  redundant,  and  costly  to  utilize. 
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Where  do  purchased  software  packages  fit  in  an  environment  in  which  integration, 
coordination,  and  flexibility  are  key?  First,  off-the-shelf  packages^  that  cannot  easily  be 
customized  may  be  appropriate  for  business  practices  that  do  not  need  a  lot  of  flexibility, 
such  as  certain  areas  of  accounting  and  human  resources.  Second,  a  new  breed  of  packages 
is  now  appearing  -  software  packages  built  using  CASE  tool  -  that  can  be  more  easily 
changed  and  more  easily  coordinated  with  the  rest  of  the  organization's  IS  portfolio. 

We  have  now  reached  the  end  of  the  first  phase  of  the  framework  (Figure  1).  We 
have  described  the  way  in  which  our  companies  envision  the  three  future  environments. 
Given  the  expected  interdependent  change-oriented  business  environment,  and  the  expected 
integrated  systems  environment  necessary  to  support  this  business  environment,  the  shape  of 
the  necessary  future  coordinated  development  environment  is  reasonably  clear  -  as  discussed 
above.  Many  IS  organizations  are  already  moving  toward  this  development  environment  but 
in  diverse  ways. 

The  Company  Examples  Summarized  --  Phase  1 

It  would  be  useful  at  this  point  to  summarize  the  three  company  examples  in  terms 
of  the  first  three  environments  we  have  just  discussed.  Although  each  organization  is 
different,  each  to  one  degree  or  another  considered  all  three  steps  leading  to  the 
determination  of  a  future  development  environment.  In  addition,  the  companies  used 
similar  definitions  not  only  of  the  major  attributes  of  their  business  environments  but  also 
of  the  attributes  of  their  projected  systems  and  development  environments. 

•  At  the  major  insurance  provider,  the  current  and  projected  business  environment 

is  "frenetic"  -  new  products  must  be  delivered  and  current  products  adjusted  daily 
to  meet  the  changing  demands  of  the  marketplace.  Service  quality  will  be  the 
competitive  differentiator.  Vie  projected  systems  environment  accommodates  this 


^     We  are  specifically  referring  here  to  those  off-the-shelf  software  packages  that  cannot  be  easily 
customized  through  changes  to  the  code  by  the  organization  purchasing  them. 
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need  for  speed  and  quality  and  is  composed  of  flexible,  modular  systems  that  can 
be  easily  customized  for  each  new  product.  Vie  projected  development 
environment  is  a  structured  one  in  which  systems  will  be  assembled  (rather  than 
developed)  from  predescribed,  standardized  components  that  are  either  built 
internally  or  purchased. 

Globalization,  integration,  a  customer-  and  team-orientation  and  -  most 
important  -  common  business  processes  across  geographical  and  product 
boundaries  constitute  the  chemical  firm 's  projected  business  environment.  In  the 
projected  systems  environment,  information  is  accessible  to  empowered  employees. 
Transaction  systems  are  flexible  and  integrated;  they  span  traditional  divisional 
boundaries  and  support  common  business  practices.  Vie  projected  development 
environment  focuses  on  tools  and  methods  that  will  support  the  need  for  (1) 
software  reuse  in  the  development  of  transaction  systems  and  (2)  companywide 
access  to  consistent,  reliable  information. 

Vie  energy  company  recognizes  that  its  projected  business  environment  is  one  in 
which  1)  integration  across  subunits  has  become  very  important,  2)  change  is  the 
norm,  and  3)  access  to  accurate,  timely,  and  consistent  information  is  critical  to 
running  the  business.  Vie  projected  systems  environment  encompasses  a  shared 
corporate  information  architecture  and  enterprisewide,  horizontally  integrated 
systems  that  can  be  easily  changed.  Vie  projected  development  environment  is 
based  on  an  integrated  CASE  tool  that  will  produce  these  integrated,  flexible 
systems  and  facilitate  the  establishment  of  a  shared  corporate  information 
environment. 


PHASE  2:    MANAGING  THE  TRANSITION 

While  the  IS  directors  we  interviewed  described  similar  scenarios  for  the  first  three 
environments,  their  transition  paths  differed  widely. 

The  Transition  Process 

The  transition  process  is  the  tactical  implementation  of  the  envisioned  development 
environment.  Taking  into  account  the  unique  critical  factors  in  its  current  environment,  each 
organization  selected  the  specific  tools  and  methods  to  be  installed  in  the  short  and  medium 
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term  in  order  to  migrate  toward  the  projected  development  environment.  Each  of  the  three 
companies  we  have  discussed  chose  a  different  initial  path. 

•  The  Insurance  Company.  Vie  new  senior  IS  executive  inherited  an  environment 
that  necessitated  a  relatively  slow  transition  process.  While  his  ultimate  goal  is 
to  have  an  integrated  CASE  environment,  he  has  decided  that  purchasing  an 
integrated  CASE  tool  would  be  too  big  a  change  for  his  IS  organization.  Instead, 
he  is  taking  a  gradual,  step-by-step  approach,  first  purchasing  a  code  generator, 
then  purchasing  an  analysis  tool,  and  so  on.  He  is  also  investing  in  education 
and  training  in  order  to  slowly  change  the  culture  and  upgrade  skills. 

•  The  Chemical  Firm.  With  its  current  emphasis  on  empowerment  of  individuals, 
the  transition  at  this  firm  emphasizes  the  provision  of  relational  information 
databases  and  other  tools  for  the  information  support  systems  and  the  use  of 
standard  packages  worldwide  for  the  transaction  systems.  At  the  same  time, 
significant  time,  effort,  and  dollars  are  being  invested  to  change  the  IS 
organization  in  terms  of  both  structure  and  individual  attitudes  about  roles  and 
responsibilities.  These  changes  are  being  enacted  as  quickly  as  possible  in  this 
very  large  IS  organization. 

•  The  Energy  Company.  Tfiis  firm  is  making  the  fastest  transition:  management 
purchased  an  integrated  CASE  tool  and  established  a  user  information 
environment.  At  the  same  time,  it  made  major  investments  to  change  certain 
aspects  of  its  structure,  management  processes,  and  system  infrastructure. 
Significant  time,  dollars,  and  effort  have  been  spent  to  reorganize,  retrain,  and 
educate  the  IS  group  in  order  to  change  the  skills  and  perspectives  of  IS 
personnel.  Only  with  senior  management 's  fidl  understanding  and  strong  backing 
could  this  transition  process  be  carried  out  so  quickly. 


These  organizations  anchored  their  transition  decisions  in  the  context  of  both  their 
future  and  current  environments.  The  former  is  especially  important.  Without  this  longer- 
term,  business-based  context,  the  real  benefits  associated  with  these  often  expensive  choices 
would  not  have  been  clear.  Without  this  clarity,  business  executives  in  our  study  sites  would 
have  understood  only  the  cost  side  of  the  equation  without  the  corresponding  benefits. 

Whereas  the  projected  environment  indicates  what  should  be  done,  the  current 
environment  dictates  what  can  be  done.  In  choosing  the  particular  combination  of  IS 
approaches,  techniques,  and  tools  to  be  used,  our  interviewees,  either  explicitly  or  implicitly, 
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considered  a  clear  set  of  components  in  developing  their  transition  plans.  In  this  section, 
we  will  discuss  these  components,  the  way  in  which  they  interact,  and  the  ways  they  influence 
the  choices  to  be  made  in  defining  the  transition  process. 

Rockart  and  Scott  Morton,  drawing  on  Leavitt,  describe  a  conceptual  model  of  five 
organizational  components  that  must  be  kept  in  balance  when  introducing  a  change  into  an 
organization:  technology,  corporate  strategy,  organizational  structure,  managerial  processes, 
and  individuals  and  their  roles  [Rockart  and  Scott  Morton,  1984;  Scott  Morton,  1991; 
Leavitt,  1965].  The  basic  idea  is  that  changes  in  one  aspect  must  be  balanced  by  changes 
in  other  aspects  for  the  organization  to  remain  effective.  For  example,  a  strategy  change 
may  necessitate  changes  in  organization  structure,  technologies,  jobs.  Rockart  and  Scott 
Morton  use  the  model  to  discuss  the  organizational  changes  that  are  necessary  to  successfully 
introduce  technology-related  change  into  an  organization.  Figure  2  shows  this  model, 
adapted  to  describe  the  changes  necessary  to  successfully  introduce  technology  changes  into 
the  IS  organization.  Although  the  focus  here  is  on  the  components  within  the  IS 
organization,  it  is  important  to  also  consider  the  parallel  components  at  the  company  level. 
The  components  are  as  follows: 

•  Tools  and  Methods.  These  are  the  processes  used  to  create  systems  --  systems 
development  methods,  tools,  techniques,  standards,  project  management  processes,  and 
measurement  processes. 

•  Systems  Infrastructure.  This  includes  data,  applications,  and  the  underlying  technology, 
that  is,  the  hardware,  system  software,  and  network.  The  organization  needs  to  evaluate  the 
status  of  the  current  infrastructure,  the  extent  of  changes  necessary,  and  the  steps  required 
to  make  the  changes.  This  is  a  key  area  for  consideration:  a  significant  portion  of  the 
transition  process  involves  migrating  what  for  most  organizations  is  a  massive  base  of  existing 
technology,  data,  and  systems  --  often  stand-alone,  function-specific,  data-redundant  systems 
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--  into  the  new  development  environment,  and  integrating  these  previously  disparate 
solutions  to  support  the  new  interdependent  organization. 

•  IS  Organization  Structure.  IS  organizations  have  unique  structural  patterns.  One 
dimension  (centralization  versus  decentralization)  places  analysts  and  programmers  either 
close  to  or  remote  from  their  "customers."  Change  may  be  appropriate  in  this  organizational 
arrangement.  Another  dimension,  the  degree  of  specialization  within  IS.  may  be  forced  to 
change  as  new  development  tools  and  procedures  are  introduced.  For  example,  as  code 
generators  become  more  sophisticated,  there  will  be  less  need  for  the  specialized,  technical 
function  of  "programmer,"  and  greater  need  for  a  more  business-oriented  function  of 
"analyst." 

•  IS  Management  Processes.  These  are  the  procedures  that  guide  daily  operation.  Some 
of  the  most  important  are  short-  and  long-term  planning,  formal  and  informal  incentive  and 
reward  systems,  and  management  of  external  relationships  (including  vendors, 
customers/users,  etc.).   Some  are  easy  to  change;  others  are  more  deeply  entrenched. 

•  Individuals  and  Roles.  This  component  includes  people  and  their  skills,  roles,  and 
responsibilities.  Also  included  here  are  issues  of  training,  education,  and  relationship 
building,  which  may  need  to  be  changed  with  the  addition  of  a  new  development  tool.  As 
can  be  seen  in  Figure  2,  there  are  three  segments,  or  sub-components,  all  of  which  influence 
the  decisions  to  be  made.   These  are  IS,  senior  management,  and  line/business. 

IS.  Clearly,  individuals  in  the  IS  organization  -  analysts,  programmers, 
managers,  and  so  on  -  and  their  skills,  roles,  and  responsibilities  must  be 
reconsidered.  Changes  in  the  development  environment  require  changes  in 
IS  skills,  both  in  technical  areas  and  in  general  business  areas,  such  as 
communication  and  negotiation.  It  is  important  also  to  note  that  assigning 
new  roles  and  responsibilities  is  not  enough;  it  is  critical  to  also  change  the 
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assumptions  that  people  hold  about  ihose  roles  and  responsibilities  [Gash  and 
Orlikowski,  1991]. 

Senior  Management.  Development  choices  are  affected  by  how  well  senior 
managers  understand  the  process,  as  well  as  by  senior  management's  priorities 
and  the  company's  financial  constraints.  If  senior  managers  are  fully 
committed  to  the  necessary  changes,  the  IS  executive  may  be  able  to 
implement  greater  changes  in  a  shorter  period  of  time  than  if  senior  managers 
simply  recognize  --  or  do  not  recognize  at  all  --  that  change  is  necessary.  A 
lower  level  of  understanding  also  requires  a  greater  investment  in  education 
by  IS  management. 

-  Line/Business.  Similarly,  how  well  other  managers  understand  the  process  is 
also  relevant.  Certain  changes  in  the  development  environment  directly  affect 
functional  managers  and  others  who  must  rely  on  the  new  systems.^  The 
level  of  understanding  these  managers  need  depends  on  the  degree  to  which 
they  are  affected  by,  and  need  to  be  involved  in,  the  change.  In  turn,  as  is  the 
case  with  senior  management,  their  current  level  of  understanding  directly 
affects  the  amount  and  speed  of  change  that  can  be  made  [Orlikowski,  1991]. 

•  IS  Development  Strategy.    This  is  the  conceptual  approach  to  how  all  of  the  other 

components  will  be  configured  to  carry  out  the  systems  development  process.  With  a  major 
change  in  the  development  process,  the  strategy  must  include  not  only  what  will  be  done, 
but  how  the  other  components  will  be  brought  up  to  speed  through  education,  purchase  of 
tools,  change  in  processes,  and  so  forth. 


Q 

For  example,  because  cross-functional  systems  by  definition  have  multiple  user  groups,  developmg 
them  effectively  requires  a  very  different  project  management  structure  than  would  be  typical  for  the 
development  of  a  function-specific  system. 
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•  Culture.  Schein  defines  culture  as  the  "basic  assumptions  and  beliefs  shared  by 
members  of  an  organization"  [Schein,  1985].  It  relies  on,  and  is  built  from,  the  policies, 
procedures,  and  methods  that  are  associated  with  "the  way  things  have  been  done"  in  all  the 
components  of  the  diagram.  Therefore,  culture  arises  from  and  pervades  all  the  other 
components.  The  traditional  IS  culture  with  its  heavy  technical  orientation  clearly  is  not 
appropriate  for  the  organization  and  types  of  systems  required  in  the  1990s.  As  stated 
earlier,  changing  the  assumptions  which  underlie  each  component  of  this  model  -- 
particularly  where  the  status  of  a  component  has  been  relatively  stable  for  a  long  while  -- 
can  be  very  difficult.  Schein  believes  that  major  culture  shifts  can  only  be  accomplished 
through  extremely  effective,  almost  charismatic,  leadership  or  by  changing  the  key  personnel 
involved. 

•  Technology  Capability.  Clearly,  an  important  factor  in  choosing  IS  tools  is  the  current 
and  expected  capabilities  of  these  tools.  Equally  important  is  the  systems  environment  (e.g., 
mainframe-centered  or  client-server)  that  is  expected  to  prevail  in  the  organization.  For 
example,  one  organization  did  not  purchase  integrated  CASE  tools  because  current  CASE 
technology  did  not  support  its  emerging  client-server  environment. 

It  should  be  noted  that  the  above  components  represent  a  composite  picture;  all 
factors  were  not  mentioned  by  each  interviewee.  However,  all  are  important.  One  cannot 
install  a  new  development  process  without  the  appropriate  balance  of  IS  personnel  skills, 
technical  infrastructure,  senior  management  understanding,  and  so  on.  The  problem  of  a 
lack  of  balance  in  upgrading  an  organization  has  been  dramatically  illustrated  in  the 
automobile  industry  [McKersie  and  Walton,  1991].  In  some  plants,  huge  investments  have 
been  made  in  production  line  technology.  However,  the  lack  of  equivalent  investments  in 
education  and  training  of  plant  employees  has  made  these  investments  ineffective  and  costly. 
The  key  question  for  IS  management  is:  given  the  current  status  of  all  the  existing 
components,  how  much  can  each  component  be  changed,  while  maintaining  the  necessary 
balance?   And,  therefore,  what  should  the  transition  plan  look  like? 
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To  develop  the  transition  plan,  the  IS  executive  must  first  evaluate  the  current  status 
of  the  organization  in  terms  of  these  components.  Second,  the  IS  executive  must  consider 
and  address  the  interaction  and  necessary  changes  in  each  of  these  components  for  any 
proposed  change  in  development  tools  to  be  successful.  A  change  in  one  component  will 
likely  necessitate  action  in  others  in  order  to  keep  them  m  balance.  Magnitude  is  another 
important  factor  --  a  change  that  represents  a  major  shift  from  current  practice  will  affect 
a  greater  number  of  components  and  will  affect  each  one  to  a  greater  degree.  In  considering 
a  major  change  to  the  systems  development  process,  the  IS  executive  must  determine 
whether  the  necessary  financial  and  human  resources  exist  to  reach  the  stated  objectives. 

CONCLUSION 

Understanding  and  implementing  a  major  change  is  complex  and  often  nonlinear. 
The  neatness  of  the  cases  and  the  process  presented  here  is  perhaps  misleading.  In  fact, 
some  of  the  IS  executives  we  interviewed  first  visualized  the  systems  and  development 
environments  and  then  urged  senior  management  to  think  through  the  business  environment 
as  a  means  to  facilitate  the  senior  managers'  understanding  of,  and  support  for,  the  required 
investment.  In  almost  all  cases,  however,  managers  paid  attention  to  all  of  the  steps  in  both 
phases. 

In  closing,  we  believe  five  points  are  worth  emphasizing.   They  are  as  follows: 

The  Change  is  Critical.  In  most  of  the  companies  we  visited,  the  similarity  in  projected 
business,  systems  and  development  environments  was  striking.  If  the  IS  organization  is  to 
keep  up  with  the  business's  future  needs,  a  new  systems  development  approach  is  absolutely 
necessary.   The  question  is  not  whether,  but  when  and  how. 

The  Choices  are  Strategic.  Too  often  organizations  discuss  the  issues  in  this  paper  at 
an  operational  level.  It  has  become  increasingly  clear  that  decisions  regarding  systems 
delivery  mechanisms  are  strategic  in  nature,  are  major,  and  must  be  addressed  by  senior 
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management.  Moreover,  significant  time  and  energy  must  be  spent  planning  and  executing 
the  transition  process  and  the  necessary  "balancing"  investments  in  education,  training,  new 
methods,  and  so  forth. 

The  Change  is  Ongoing.  It  is  important  to  recognize  that  the  three  future 
environments  depicted  in  the  framework  will  not  —  and  should  not  —  be  defined  and  then 
frozen.  The  future  environments  represent  strategic  intent  and  should  continue  to  evolve 
as  realities  change.  The  ability  to  accommodate  and  manage  such  uncertainty  requires  a 
change  in  people's  assumptions  and  mental  models  about  change.  Tfiis  is  not  an  event:  this 
is  a  process. 

Context  Determines  the  "Portfolio  of  Solutions."  Returning  for  a  moment  to  our  original 
scenario:  who  is  right,  the  vice  president  of  information  systems  arguing  for  CASE  tools  or 
the  SBU  manager  arguing  for  packages?  The  answer  is  neither.  Neither  CASE  tools  nor 
packages  by  themselves  will  provide  the  answer  to  any  organization's  total  set  of  needs. 
Rather,  each  organization  must  (1)  design  a  combination  of  delivery  mechanisms  that  will 
serve  its  particular  needs  and  then  (2)  reposition  the  organization  to  achieve  excellence  in 
delivery.  The  combination  must  depend  on  the  organization's  envisioned  future  and  on  its 
current  capabilities.  What  is  wrong  is  the  selection  of  a  particular  path  without  the  type  of 
careful  analysis  suggested  by  our  framework. 

This  is  a  Major  Business  Process  Redesign.  The  key  business  process  of  the  IS 
organization  is  the  systems  development  process.  Changing  the  way  systems  are  delivered, 
therefore,  is  a  major  "business  process  redesign."  IS  often  helps  other  functions  redesign 
their  business  practices,  placing  special  emphasis  on  helping  them  to  meet  future  as  well  as 
current  needs  and  to  redesign  the  associated  roles,  processes,  and  structures.  If  the  cobbler's 
children  are  not  to  be  without  shoes,  the  same  thinking  must  be  brought  to  bear  on  the 
redesign  of  the  systems  development  process. 
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